NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/applications/305

Internet Message Format | 1996-08-05 | 17.5 KB

Path: news.mindspring.com!chmood
From: [e-mail] (Charlie Moody)
Newsgroups: comp.sys.amiga.applications
Subject: [FinalWriter] Design Considerations, Features, etc
Date: 8 Jan 1996 16:02:35 GMT
Organization: Photobooks Inc
Message-ID: <4crf6r$[e-mail]>
NNTP-Posting-Host: photobooks.atdc.gatech.edu
X-Newsreader: TIN [version 1.2 PL2]

Here is the file I've mentioned.  It began as a letter to SoftWood, and I
haven't bothered to change it, stylistically.  It includes observations
and recommendations regarding FW design and implementation *beginning* w/
2.1, and carried thru 3.0.

I hope that both SoftWood and Digita read this, and I welcome comments.


--------------------  snip  -------------------------  snip  ---------------

 FinalWriter release 2.1 / 3.0:   Request for Modifications and Enhancements



Let me begin this by thanking you for producing a text engine for the
Amiga that is worthy of being improved.  Despite early frustrations,
inadequate (tho attractive) documentation, and the ongoing confusion of
trying to intuit your implementation of various features, my estimate of
FW's value has gone up: especially since I received the 2.1 upgrade.  The
addition of so simple a feature as the paragraph strip has dramatically
increased FW ef- fectiveness for me (why do you call it a paragraph strip?
I think I'd call it a text strip.)



I've spent many hours compiling and refining the suggestions here, and in
the process, I've arrived at a few fundamental criticisms of FW's
operation and (in places) design.  As a retired software jock, I've found
myself putting on my design hat in doing so.  I hope that you'll give
serious consideration to my suggestions for enhancements, as I believe
they can lift FW to the top rank of word processors regardless of
platform.


My overall observations?  First, that FW is slow.  Opening at startup,
opening a new window (opening "Untitled", then loading the chosen
document), changing from one window to another, synchronous printing,
changing from arrow-pointer to insertion-pointer ('][') - waiting for
these is annoying and distracting. The culprit often seems to be multiple
unnecessary screen redraws; surely you can easily check to see if a
document uses custom palettes, strips, etc., and then draw the window
accordingly, once!  (If each doc has its own prefs structure, this should
be easy....)


Program preferences and document defaults strike me as confusing,
illogical and lacking in power & features.  Of all the areas I feel need
improvement, this area of program and document control (and the
opportunities to change these things that are scattered throughout the
program) stands out as being in the greatest need. Accordingly, I'll
discuss this area in some detail below.


It may be that making such changes as I propose here will require major
design revision:  I certainly hope not;  and yet, such possibility exists
in any project involving ongoing development, and there is no reason why
FW3 couldn't set a new standard in w/p design & implementation.  I hope it
will!



BUGS

Menu selections only take effect if the pointer is showing the '][' image
during the selection. Menu access should be enabled regardless of pointer
type. As mentioned above, the time required for the pointer image to
change is excessive:  please find a way to speed it up.

Hyphenation:  terms, such as 'self-defense', which contain suppled
hyphens, are not handled correctly. In the document I'm working with (in
the other window), 'self-defense' is treated as one word, and it is bumped
to the next line as a whole; attempting to defeat this by typing 'self-
defense' (breaking it into two words) results in 'self- def' at the end of
one line, and 'ense' at the beginning of the next. This should never
happen!  Words containing supplied hyphens should break following the
supplied hyphen. Strings containing slash characters ('/') should treat
these as supplied hyphens, per above, for correctly breaking pathnames and
other compound constructions.

Top margins are not retained during final printing.  I've enclosed a
sample page displaying this, encase you haven't seen it.



SHORTCOMINGS THAT COULD ALMOST COUNT AS BUGS

A flashing cursor option should be available, as well as cursor color
selection.

FW will abort an Open-Document request if the user specifies a file name
that doesn't exist in the selected drawer.  FW should create the file,
then open it - not just bail out w/ a screen flash!

ASCII files should be treated as ASCII ASCII files are automaticaaly
converted to FW format.  This should be made explicit by requiring the
user to import as, or export to, a FinalWriter file.  Similarly, exporting
as ASCII should allow exported lines to wrap as one would expect, and
avoid hard EOLs.  I wrote this file in FW 2.1 & FW 3.0, exported it to
ASCII, and am adding this line during my cleaning-up of the file.

Keyboard control for moving from word to word requires two hands:  this
should be at least possible as a one-handed operation.  I recommend you
swap control keys for this function w/ those now used for block selection:

    shift-arrow      =    move word-to-word or paragraph-to-paragraph
    ctrl-arrow       =    highlight characters / line fragments
    ctrl-shift-arrow =    highlight words / whole lines

Draft-mode printing doesn't preserve general formatting attributes such as
bolding, centering, italics, underlining, margins, etc.  As a result,
draft copies can't be used to check and correct formatting
inconsistencies. This drastically reduces the value of having a draft copy
in the first place. Draft-mode printing should preserve all standard
formatting attributes via the standard Amiga printer commands.



ENHANCEMENTS and MODIFICATIONS

FW General


Operational Defaults

Every task that can run asynchronously should do so:  printing, saving,
the speller, and the thesaurus are all examples of tasks that should not
disrupt or interrupt the users' work.

FW still lacks any sort of default font list (other than SoftSans), as
near as I can tell.  Such a list, which FW would use to 'load' the
font-selection popup on the toolstrip, would be a terrifically useful &
worthwhile feature, as would the ability to purge the open-fonts list.
Without such a list, the user must manually call up the
Text/TypeStyle/Open requestor once for every font the user wants to choose
from, select the font, and then do it again!  With a default fontlist, the
user's preferred selections are available at start-up Also, the open-fonts
list should be able to handle global font selections, not just local
(document-specific) choices.



DOCKING!

The ability to dock a given document or the entire program would be a
terrific feature - a ToolMaster-style list of buttons, showing the titles
of each open document, plus buttons for 'Open New' and 'Open Existing';
clicking one of these buttons would open that document's window on FW's
default screen.  If FW opens its own screen, the dock should pop up onto
the FW screen when it opens, so that the working set of documents is still
easily available.  This would simplify and streamline FW's behaviour and
performance, greatly increase its convenience and ease of use, and could
conserve memory as well.

Along the lines of the default fontlist I mentioned earlier (not to
mention a font dock!), a default docklist would be a great additional
feature:  a list of docs that would be loaded into the FW Dock @ start-up.
For example, if FW found a 'docklist.cfg', then it would open its dock on
the Workbench, showing those documents.  The ability to create and change
such lists, along with the ability to tell FW which list should be
'docklist.cfg', should also be provided.  This would be terrifically
useful when working on several different projects, as many writers do
(like me!).

As an alternative to docking, the user should be able to choose either an
AppIcon, or a 'tuck-away' icon of the title-bar or 'sleeping-program'
type.


Backup Control

Generational backups (i.e., #?.BK1, .BK2, .BK3, etc.) should be
implemented, at least as a selectable default option.  Sometimes it's
highly desirable to return to an earlier stage in a project, and to be
able to do so without resorting to tricky manual procedures.

The auto-save feature should be completely automatic, once it has been
selected by the user, without making further queries, and without
requiring continual user input.  At the least, the user should be able to
select either auto-mode or intervention-mode as a default.

Note:  this *was* added in 3.0, but it was implemented as document-local,
not global.  This is silly.  The feature is ALSO keyed to mouse movement,
which is even sillier, as one can (& does) get a lot of typing done
without using the mouse.

The auto-save feature should save asynchronously, to avoid interrupting
the user's work, and to eliminate the slow and annoying screen-redraw and
pointer-lag that follows every save.


PREFERENCES and DEFAULTS

FW's preference and parameter 'scheme' may provide very powerful aids, but
the way they are implemented creates unnecessary confusion. There seem to
be too many ways to mess with standard parameters -lots of opportunity for
users to get in their own way.  An actual prefs program or subsection
would be a real boon. It should clearly indicate a configuration or
preference hierarchy.  For example:

PREFS:Program, Documents, Display, Misc.

      Program/Screen/Paths/General
          Screen(DefaultScreen/Resolution, Colors, FlashingCursor?)
          Paths(Docs/clips/speller/styles/fonts/macros/graphics/backups/
            printer/arexx)
          General(Dock/Iconify[AppIcon/'StickAway'Icon]),
          DockList[New/Edit/SelectDefault], ForceARexxActive,
          BackUpControl(AutoSave/Frequency/Prompt/Nr-of-Generations)
          DefaultPrinterDriver

      Documents/Defaults/Filters/Text/General
          Defaults(Document, Page[LeftMaster/RightMaster/Body],
               Section/ByType/ByName/Paragraph/Styles/ToC/Index)
          Filters(MaintainASCII[Always/Never/Ask])
          Text(FontList[New/Edit/Default],TypeControl[Attributes/Styles]
          General(Speller/Thesaurus/Hyphenation/Bibliography]

      Display/Windows/ButtonSets
          Windows(Documents[Anchored/Floating]/Palettes[Anchored/Floating,
              Snapshot[Sizes/Positions])
          ButtonSets(Create/Edit[Sets/Images]/SelectStripSets[range],
             SelectPaletteSets[range]/Show/Hide)

This example prefs layout is reasonably consistent with standard
approaches to prefs selection, as well as being reasonably flexible,
powerful, and consistent in its own right.  I think it is also more
intuitive and more predictable than FW's preferences hierarchy as of 3.0.
I've taken the liberty of using it to show a number of options I'd very
much like to see in FW.

Here are some specific notes detailing the examples above (for detailed
comments on handling document preferences and parameters, see the section
on Documents, below):

Graphics/Display:

Options should be meaningful, i.e.: screen resolution choices, rather than
cryptic x/y dot counts or "Model T"-style screen selectors ('choose any
screen, as long as it's this one').  Provision should be made to take
advantage of graphics boards (including the ZII Retina, please!), making
use of the speed, memory, and options that these cards present.

Anchoring doc & palette windows:  This would prevent the 'floating
palettes' from diving beneath the active window when using FW with
window-activation commodities, and otherwise prevent the various windows
from getting in each other's way. As a minimum, I suggest that users be
allowed to choose Anchored (bottom-layer) documents and floating
(top-layer) palettes as one option, and the reverse (floating docs &
anchored palettes) as the alternative.

The document window should collapse or expand to show the selected button
strip(s);  currently it will display up to 3, which is fine. However,
button strips and palettes should be mutually exclusive:  a button set can
be one or the other (or unused) at any moment, but not both at once.
Also, restrictions on what can be displayed as a strip should be
eliminated:  For example, I can have either the toolstrip or the paragraph
strip, but not both (of course I want them both!);  also, I can have the
button strip, or not, but I can't replace it with the toolstrip (of course
I want to replace it with the toolstrip!).

Also on the subject of button strips, etc.:  A graphic list of the
supplied buttons and their default assignments (separate from the
definition requester) would be wonderfully helpful in creating and editing
strips & palettes.  I'm surprised that such a list isn't provided in the
manual.



DOCUMENTS


Outlining

An outline processor similar to ThinkTank should be available, which could
be used to outline a project simply & easily, and from which the full work
could then be developed directly.  Your option to generate an outline 'ex
post facto' may be useful, but I use outlines to *generate* documents.  I
want outlining tools in FW so I can then expand the outline into the
article in a single process.  I'd consider a well designed & implemented
outliner worth upgrading for all by itself!


Printing

A printer-preferences selector (like your pop-up fontlist) would be a real
boon to those of us who have & use more than one printer.

A print-queue option:  the ability to select, order, and asynchronously
print multiple documents as a single task, either to paper or to disk (one
file per document).  As mentioned above, ALL print jobs should run
asynchronously - else what's multi-tasking for?

Section access in a document should be more direct.  The paragraph strip
is a perfect place for a pop-up offering an alphabetized list of the
sections in the current document, showing the current section, and
providing one-click access to any section.  I would certainly use this
feature much more often than I'll use the capitalization popup, or the
sub/super script popup.


Parameter Modification

A clear precedence should be established to show the chain of effect that
modifications create.  For example:

   Default Document  uses the default section, page, paragraph, and fontlist
   Default Section   uses the default master and body pages
   Default Page uses the default paragraph
   Default Paragraph is the default paragraph style, uses the default typestyle
   Default Typestyle

Each set of default parameters should be accessible only from the
preferences. Any modifications not saved should be document-local.


Document-local parameter modifications should be linear in presentation,
as well as local in effect.  Example:

Document:  [options] - modify anything not handled by the other panels
       [section] - modify the document's current section
       [page]    - change page param's for the entire document
       [type]    - set/change typeface/typestyle for entire document
              (this might help overcome the problem of pasted text
               changing typeface/style/font/whatever)

Section:   [options]   - manipulate the current section
       [page]      - modify the current page for the section only
       [paragraph] - modify the paragraph style for the section only

Page:       [options] - manipulate the document's current page

There should be no interlinking between these, or the hierarchy is broken
and the changes become unpredictable.  If the top level was a popup on a
strip, and the options presented panels as described, I think it would
greatly help the user to keep its bearing and wits about it while slogging
through a document. In FW, I continually find myself thinking I've set an
option, then discovering that I hadn't set the right thing, or that I'd
set it in the wrong place, such as trying to set something globally but
only affecting the document, or making a change in the doc & discovering
I've changed the program defaults.

Maybe this will get the point across:  all settings should be
document-local unless the program defaults are changed explicitly!!!

ALL font and type modifications should be localized, as with the prefs,
and should be on a panel, rather than forcing the user to wade through
repetitive menu selections that require going in, changing one thing,
going back in to change another, etc. Text styles should be created as a
specific option of this standard control panel.

As above, paragraph parameter modification should be localized, and styles
created (and textstyles assigned) as a specific selection from the one
standard control panel.

Page- and section-parameter modification should adhere to this same rule,
with the shared exception of permitting the user to toggle back and forth
between master- and body-page option selectors (or between sections) while
still in modification mode.

Page styles (i.e. columnar styles, survey/questionnaire styles, outline
styles, correspondence styles) or templates could be implemented
compatibly w/ other styles (perhaps even document styles such as FW,
ASCII, PostScript).

Default master pages for each section should be available as well as a
default body page.

I'd like FW to have the ability to find and start arexx if arexx is
inactive @ start-up.

I'd like to see FW's documentation approach the standard of detail and
thoroughness set by Soft-Logik for their PageStream 3. For example, what
little information the FW manual presents on headers and footers is spread
throughout the manual in repetitive bits;  I would like to see this, and
other topics, covered thoroughly and once.



Thanks for your attention to my suggestions.  I've spec'd, designed, and
coded software myself, and written documentation, and done my time on the
tech support phones, so I hope you'll forgive me if you feel there's too
much detail;  I believe these changes are basic and reasonable, and will
add substantially to FinalWriter's usability, friendliness, and value.